Cloud based software is altering the way users work and live as well as the operation and management of today's enterprises. Cloud software involves publishing Service Level Agreements (SLA) to which cloud based software service providers observe and adhere. The relationship between the software service providers and the customers are typically governed by the Service Level Agreements. If the software service provider or the customers violate certain agreements or if the service level objectives are not satisfied, penalties may be incurred. The Service Level Agreements involve guarantees regarding uptime and availability. They may also promise a turnaround time for a first response or a time for completion for items like service tickets. This process requires human intervention for estimating suitable time threshold guarantees for responding to or completing tasks/items like service tickets. The uniqueness of each service ticket and the fact that service tickets are processed by humans makes it very difficult to estimate the time threshold guarantees for service tickets.
In a cost based approach for estimating the suitable time threshold, support costs associated with the first response/completion of tasks/items are calculated. Since each SLA breach is associated with a penalty, Penalty versus Support costs graph is plotted with costs on Y-axis and the percentage of items being responded to or completed on X-axis. As the percentage of items completed within SLA increases, the support costs rise but SLA breach costs come down. In other words, the more items which are completed or responded to within SLA time thresholds, the higher the support costs but lower the SLA breach penalty. The intersection point of the two curves is the break-even point. By using historical first response/completion time versus a percentage of item graphs, users can map the percentage of items at the breakeven point to estimate the time thresholds. However, this approach is very impractical to implement as cost graphs are not readily available and SLA penalty may not be determined until SLA thresholds are identified (so it cannot be relied upon to be available as an input).
In an alternate method, a user could use historical first response/completion time's graph for identifying suitable time thresholds. As the support costs are inversely correlated to time threshold values (i.e. bringing down time threshold values may mean more hiring and consequent increase in support costs), relying on the graphs with just completion/first response times serves as an approximation for the graphs with actual costs. Plotting of graphs between completion/first response times versus percentage of items is much easier than those of support costs, and also this method does not require SLA penalties as input which makes this approach a practical alternate method for identifying time thresholds. Once time thresholds are identified using completion/first response time graphs, users can figure out the support cost for the suggested time threshold, if the Support cost graphs are available. Hence, user can also figure out the SLA penalty value to recommend for SLA breaches.
Even with the completion/first response time graphs, picking the right threshold value to maximize the percentage of items being responded to or completing within the threshold while ensuring that the threshold value is not very high is challenging. Moreover, it is even more challenging to estimate the suitable threshold values where historical completion or first response time data is not available.
Accordingly, there remains a need for a system and method for determining a time threshold guarantee for responding to or completing a task/item.